Skip to content

Use Order API to create recur directly for Formbuilder payments - #35995

Draft
mattwire wants to merge 1 commit into
civicrm:masterfrom
mattwire:orderapi_recurfb
Draft

Use Order API to create recur directly for Formbuilder payments#35995
mattwire wants to merge 1 commit into
civicrm:masterfrom
mattwire:orderapi_recurfb

Conversation

@mattwire

@mattwire mattwire commented Jun 17, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Overview

When Formbuilder payments was first written Order API did not support recurring contributions. Now it does. So let's use it!

Before

Separate function, after Order API called

After

Created using Order API

Technical Details

Comments

@civibot

civibot Bot commented Jun 17, 2026

Copy link
Copy Markdown

🤖 Thank you for contributing to CiviCRM! ❤️ We will need to test and review this PR. 👷

Introduction for new contributors...
  • If this is your first PR, an admin will greenlight automated testing with the command ok to test or add to whitelist.
  • A series of tests will automatically run. You can see the results at the bottom of this page (if there are any problems, it will include a link to see what went wrong).
  • A demo site will be built where anyone can try out a version of CiviCRM that includes your changes.
  • If this process needs to be repeated, an admin will issue the command test this please to rerun tests and build a new demo site.
  • Before this PR can be merged, it needs to be reviewed. Please keep in mind that reviewers are volunteers, and their response time can vary from a few hours to a few weeks depending on their availability and their knowledge of this particular part of CiviCRM.
  • A great way to speed up this process is to "trade reviews" with someone - find an open PR that you feel able to review, and leave a comment like "I'm reviewing this now, could you please review mine?" (include a link to yours). You don't have to wait for a response to get started (and you don't have to stop at one!) the more you review, the faster this process goes for everyone 😄
  • To ensure that you are credited properly in the final release notes, please add yourself to contributor-key.yml
  • For more information about contributing, see CONTRIBUTING.md.
PR commands & links...
  • /rebase <branch-name> will rebase your branch and change the base of the PR.
  • /squash will combine all commits (keeping only the first commit messsage).
  • /port <branch-name> will create a copy of this PR against a different branch.
  • /lintroll will automatically fix linting errors, amending commits as needed.
  • retest this please will rerun the tests and rebuild the demo site.
  • 📖 Review standards
  • 🗒️ Review template (brief or verbose)

➡️ Online demo of this PR 🔗

@civibot civibot Bot added the master label Jun 17, 2026
@mattwire
mattwire marked this pull request as draft June 24, 2026 20:57
@mattwire
Use Order API to create recur directly for Formbuilder payments
aa0d657 
Formbuilder's Afform contribution submission (CreateContribution::saveNewContribution) used to create the Contribution via Order API and then create the ContributionRecur separately afterwards, manually copying contact_id/amount/currency/is_test across from the just-created Contribution. Order API now supports recurring contributions directly, so pass the recur values straight into Order::create() and let it create both records.

Order::calculateSharedValues() reconciles currency/is_test between the Contribution and ContributionRecur when only one side provides a value, so callers don't have to specify both. It runs before the ContributionRecur is created (calculateContributionRecurValues() creates it immediately when there isn't an existing one), otherwise a value provided only on the Contribution side would be too late to reach it.
@mattwire
mattwire marked this pull request as ready for review July 28, 2026 17:13
@ufundo

ufundo commented Aug 3, 2026

Copy link
Copy Markdown
Contributor

@mattwire I've been trying to get my head around this and #35996

I like the general idea here a lot and the code looks good to me.

But I'm stumbling on the following discrepancy between Contribution and ContributionRecur:

Contribution:

  • Contributions are effectively just invoices = amount payable + date = commitment to pay
  • they are neutral with respect to Payments, which are separate
  • you can set up a Contribution without paying it
  • you could use multiple different payment processors to pay different chunks of a contribution

ContributionRecur

  • for ContributionRecur it is both the "repeating invoice" = commitment to pay certain amount on a certain date
  • and it is directly linked to a specific payment processor, and often has payment processor related details ("subscription id"...)
  • that makes a mockery of the otherwise clean division in Afform Contributions between "create the contribution" and "pay for the contribution"
  • currently it's slightly fudged - create the ContributionRecur without a payment processor id, and then later update if needed (see e.g. https://lab.civicrm.org/extensions/paypal/-/blob/dev/Civi/Paypal/CheckoutOption/PaypalComplete.php?ref_type=heads#L260 )

Are you at all worried about this discrepancy? Do you have any thoughts on how to handle it?

Does Order API for recurring contributions allow setting the payment processor (and associated details)?

@mattwire

mattwire commented Aug 7, 2026

Copy link
Copy Markdown
Contributor Author

ContributionRecur

  • for ContributionRecur it is both the "repeating invoice" = commitment to pay certain amount on a certain date
  • and it is directly linked to a specific payment processor, and often has payment processor related details ("subscription id"...)

ContributionRecur is the subscription schedule and payment method. In the case of a direct debit you can think of it as the "mandate". It is not an invoice but you can expect invoices to be opened because of it.

It's only fudged because afform payments doesn't add the payment processor ID, quickform does. Because Order API didn't support recurring until early this year you had to do separate calls to create the recur.

Are you at all worried about this discrepancy? Do you have any thoughts on how to handle it?

Does Order API for recurring contributions allow setting the payment processor (and associated details)?

This PR will actually need a bit of rework once #35996 is merged - as long as the params are passed into order api they will be saved.

@mattwire

mattwire commented Aug 7, 2026

Copy link
Copy Markdown
Contributor Author

Marking draft pending merge of #35996

@mattwire
mattwire marked this pull request as draft August 7, 2026 21:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

has-test master

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@mattwire @ufundo